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DYNAMICALLY ASSIGNED SWITCHING MODELS FOR 
CONVERGED SERVICES PLATFORM 

BACKGROUND OF THE INVENTION 



Field of the Invention 

The present invention relates generally to the field of telecommunications and, 
more specifically, to a converged services platform based on a hybrid switching archi- 
tecture. 

Background Information 

Traditional circuit-switched telecommunications networks, including the public 
switched telephone network (PSTN), typically include switches in which call control sig- 
naling is fully integrated with media switching. Call processing functionality must be 
tightly coupled, and usually co-located, with media switching hardware in order to im- 
plement the traditional switching model. Thus, a switch which operates in accordance 
with the traditional model consists of a single "box" containing a call processing element 
(e.g., a CPU running appropriate software), a switching element {e.g., a timeslot inter- 
changer), one or more line cards capable of supporting desired protocols (e.g., DS3, Tl, 
El, Jl, analog, etc.) or other interfaces {e.g., SS7, IP, etc.) and, in most instances, a capa- 
bility for performing tone generation/detection, voice recorded announcements, 
conferencing or similar "media services" as may be required by a given application. 

A major disadvantage of the traditional switching model is that, due to the tight 
coupling between call processing and media switching hardware, it is not particularly 
flexible and is not well suited to rapid development and deployment of new telecommu- 
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nications services. In addition, use of the traditional switching model often requires 
higher capital investment to provide a given service due to the duplication of hardware at 
multiple locations in a large system. 

In the past several years, a growing emphasis on the use of packet-switched net- 
5 works to provide telecommunications services has given rise to an alternative switching 
model known as "soft-switching." Broadly speaking, the soft-switching model is based 
on a decoupling of call processing from media switching. Such decoupling provides 
greater flexibility for development and deployment of new services and enables con- 
struction of systems in which call processing functionality may be geographically remote 
10 from media switching hardware. Such geographical distribution is naturally compatible 
with packet-switched networks and provides numerous advantages, including elimination 
of duplicate hardware which would normally be required by use of the traditional 
switching model. 

However, the soft-switching model exhibits disadvantageous characteristics in 
15 certain applications. For example, latencies in controlling media switching entities over 
packet-switched networks may be sufficiently large as to cause noticeable delays in 
playing tones or announcements to a subscriber, which may in turn cause the subscriber 
to discontinue use of service. Such an outcome is commercially unacceptable and cannot 
be tolerated by carriers or other service providers. 

20 SUMMARY OF THE INVENTION 

In brief summary, the present invention provides a converged services platform, 
based on a hybrid switching architecture, in which switching functions may be performed 
in accordance with either a traditional switching model or a soft-switching model. In a 
preferred embodiment, the choice of switching model is programmable through applica- 
25 tion software which controls the overall operation of the converged services platform. 
The application software may dynamically assign a switching model on a call-by-call ba- 
sis. In addition, the choice of model may be dynamically changed during the duration of 
a call. 
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By allowing the application software, and thus the application developer, the 
flexibility to dynamically assign and change switching models on a per call basis, a 
highly diverse collection of applications may be optimized to very high performance in 
conjunction with a single converged services platform. That is, the present invention al- 
5 lows application developers to avoid making exclusive choices between switching mod- 
els and the performance tradeoffs associated with each such model. Instead, an applica- 
tion developer may simply select the switching model which best suits the requirements 
of a given call within the application and may do so without affecting any other call. 

Another advantage provided by the present invention relates to the use of media 
10 resources. Media resources, such as those needed to generate/detect tones, provide 

conferencing, playback voice recorded announcements and the like, are often relatively 
expensive components of a given system. Thus, there is usually an economic reason for 
minimizing such resources. With the present invention, media resources may be arranged 
as a media server located in a single, essentially central, location, but which may be effi- 
15 ciently utilized by switching hardware which is either co-located with or geographically 
remote from the media server. 

The present invention may advantageously be used with existing switching plat- 
forms that were originally designed to operate exclusively using a traditional switching 
model. By making appropriate modifications and additions to the operating software of 
20 such a platform, the capabilities of the present invention may be realized in a way that 
both extends the useful life and increases the revenue-generating capability of existing 
platforms. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention description below refers to the accompanying drawings, of which: 
25 Fig. 1 is a block diagram of a converged services platform having dynamically as- 

signable switching models in accordance with a preferred embodiment of the present in- 
vention; 
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Figs. 2A and 2B are functional block diagrams of a traditional switching model 
and a soft-switching model, respectively, constructed in accordance with a preferred em- 
bodiment of the present invention; 

Fig. 3 is a call flow diagram illustrating a series of higher level events and mes- 
5 sages which may be used to connect a call using the soft-switching model of Fig. 2B; 

Fig. 4 is a call flow diagram illustrating connection of a call using the soft- 
switching model in which an early media path setup; 

Fig. 5 is a call flow diagram illustrating a call in which a two-way voice path is 
changed to a two-way data path during the duration of the call; and 
10 Fig. 6 is a call flow diagram illustrating an interactive voice response application 

in which both a two-way TDM voice path and a two-way RTP voice path are established 
during the duration of the call. 

DETAILED DESCRIPTION OF AN ILLUSTRATIVE 

EMBODIMENT 

15 Fig. 1 shows a converged services platform (CSP) 2 which is controlled by an ap- 

plication program (not shown) running on a host computer 4. Hardware and software 
which may be used to implement a converged services platform of the type shown are 
available from Excel Switching Corporation of Hyannis, Massachusetts. With the inclu- 
sion of appropriate cards discussed below, platform 2 is capable of interfacing with both 

20 the PSTN 6 and an IP network 8. 

As shown, platform 2 includes redundant switching buses 10a and 10b. Redun- 
dant CPU cards 12a, 12b are connected to buses 10a, an HDLC bus 14, and to host 4 by 
way of input/output (I/O) cards 16a, 16b. Depending upon the requirements of a par- 
ticular application, various combinations of the following "line" cards, each of which 
25 supports a particular digital telecommunications protocol, may be included within plat- 
form 2: Tl card 16; El card 18, DS3 cards 20a, 20b. For redundancy, a standby card 22, 
which is a duplicate of one of the other line cards, may also be included. All such line 
cards have an associated I/O card, denoted collectively by reference number 26, which 
serves as an interface to PSTN 6. 
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If a particular application requires ISDN signaling, ISDN PRI cards 24a, 24b may 
be included within platform 2. Similarly, if a particular application requires SS7 signal- 
ing, SS7 cards 28a, 28b may be included. If a particular application requires IP media 
transport, platform 2 may include IPN cards 30a, 30b or an IPS card 32. Also, if a par- 
5 ticular application requires media services, a media resource card 38 may be included. 
Cards 30, 32 and 38 each have an associated I/O card, denoted collectively by reference 
number 40. Power cards 34a, 34b and cooling fans 36a, 36b are also present within plat- 
form 2. 

In a preferred embodiment, CSP 2 is an open, programmable, multi-service plat- 
10 form which, in conjunction with appropriate application software, may be used to imple- 
ment a wide variety of applications including prepaid calling, interactive voice response 
(IVR) systems, enhanced services and many others. In applications involving IP net- 
works, a single CSP 2 which includes at least one media resource card 38 may be used as 
a media server that is accessible by a number of geographically remote media gateways 
15 or other platforms. As a result, media resources need not be duplicated in multiple loca- 
tions and significant savings may be realized. 

Fig. 2A shows a block diagram of a traditional switching model which may be 
implemented using CSP 2 of Fig. 1. In this model, call control, signaling control and 
bearer switching functions are all integrated within and carried out by CSP 2, in conjunc- 

20 tion with an application running on host 4. In general, in order to initiate and ultimately 
connect a call between phone sets 38a and 38b, hardware consisting of an appropriate 
combination of cards 12, 16, 18, 20, 24, 28, 30, 32 and 38 (Fig. 1) must be used. The tra- 
ditional switching model is appropriate for connecting calls between phone sets 38a and 
38b which are connected to PSTN 6 or other network that does not support self-routing, 

25 connectionless communications. 

In contrast, using the soft-switching model of Fig. 2B, bearer switching is no 
longer handled by CSP 2, which retains responsibility only for call control and signaling 
control. That is, no physical switching is carried out by CSP 2 with respect to a call that 
is assigned the soft-switching model and the only hardware of CSP 2 that is required is 
30 one of CPU cards 12 and optionally one IPN card 30 if a call, during its duration, were to 
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be transitioned from the soft-switching model to the traditional switching model. The use 
of the soft-switching model is appropriate where phone sets 38c and 38b, for example, 
represent IP end points of IP network 8, which by definition supports self-routing, con- 
nectionless communications. 

5 In a preferred embodiment, the assignment of either the traditional switching 

model or the soft-switching model may be made by the application (host 4) issuing an 
appropriate message to CSP 2 at the initiation of a given call. This arrangement advanta- 
geously allows an application developer to specify the switching model deemed best for a 
particular application. Those skilled in the art will recognize that CSP 2 may be pro- 

10 grammed to default to a particular switching model in the absence of a message from host 
4. 

With reference now to Figs. 1 and 3, we shall discuss an example of a call proc- 
essed in accordance with the soft-switching model of Fig. 2B. In this example, reference 
number 40a represents a Session Initiation Protocol (SIP) End Point (EP) A and reference 

is number 40b represents SIP EP B. The process begins with SIP EP A issuing an INVITE 
message 42, via IP network 8, which is received by the CPU card 12a or 12b within CSP 
2. CSP 2 responds by issuing a 100 TRYING message 44 to SIP EP A. CSP 2 next is- 
sues a Request for Service (RFS) with data message 46 (the data being SIP EP A's Ses- 
sion Description Protocol (SDP)) to host 4, which notifies the application program that a 

20 call is beginning. The messages exchanged between the CSP 2 and host 4 belong to an 
application programming interface (API) provided by CSP 2 to host 4 implementers (e.g., 
application developers). Host 4 responds with a ROUTE_CONTROL message 50, which 
causes CSP to signal a call to SIP EP B using an available voice over IP (VoIP) channel. 

CSP 2 responds to message 50 by issuing an INVITE message 52, which includes 
25 SIP EP A's SDP as data, to SIP EP B, which returns a 180 RINGING message 54. CSP 2 
then acknowledges receipt of message 50 by returning a ROUTECONTROLACK 
message 56 to host 4, which responds with a PARK CHANNEL A message 58. CSP 2 
then issues a 180 RINGING message 60 to SIP EP A and subsequently receives, from 
SIP EP B, a 200 OK message 62 which indicates that SIP EP B is available to accept the 
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call initiated by SIP EP A. CSP 2 acknowledges receipt of message 62 by ACK message 
64. 

CSP 2 then issues a message 66 to host 4 which contains SIP EP B's SDP as data, 
thus providing the application with comparable information with respect to both SIP EP 
5 A and B. This is followed by CSP 2 issuing a CPE (answer) message 68 to host 4, which 
responds with a CONNECT with data message 70 instructing CSP 2 to process the call in 
accordance with the soft-switching model of Fig. 2B. CSP 2 acknowledges receipt of 
message 70 with a message 72. 

CSP 2 then issues a 200 OK message 74, which contains SIP EP B's SDP, to SIP 
10 EP A. At that point, a two-way RTP voice path 78 is established between SIP EP A and 
B. Subsequently, SIP EP A terminates the call resulting in a BYE message 80 passing to 
CSP 2. CSP 2 issues a BYE message 82 to SIP EP B, which responds with a 200 OK 
message 84. CSP 2 then issues a CPE message 86 to inform the application that the 
channel previously used for SIP EP B is released, followed by a 200 OK message 88 to 
15 SIP EP A and a CPE message 90 to release the other channel. 

Turning now to Fig. 4, we shall discuss an example of a call processed in accor- 
dance with the soft-switching model of Fig. 2B, but which includes an early media path 
setup. In the interest of brevity, messages shown in Fig. 4 and subsequent figures which 
also appear in Fig. 3 are not discussed again, but such messages should be understood to 

20 perform comparable, if not identical, functions in all instances. Here, SIP EP B issues a 
183 SESSION PROGRESS message 92, containing SIP EP B's SDP, to CSP 2. In re- 
sponse, CSP 2 issues a message 94 to host 4 informing the application of SIP EP B's 
SDP. Subsequently, host 4 issues a message 96 instructing CSP 2 to create an early me- 
dia path between SIP EP A and B. CSP 2 responds by issuing a 183 SESSION 

25 PROGRESS message 98 to SIP EP A. At this point in the call flow, even though there 
has not yet been an "answer" to the call initiated by SIP EP A, there is in fact a two-way 
RTP early voice path 100 established between SIP EP A and B. Thus, if SIP EP B now 
plays a recorded announcement, it will be heard by SIP EP A. 

Fig. 5 is a call flow diagram illustrating a call which begins with a two-way voice 
30 path but is transitioned to a two-way data path while in progress. An example of where 
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this technique may be needed would be an application which begins with a voice call, 
perhaps prompting a user to identify themselves and progress through a menu, followed 
by a fax transmission or data by modem. To accommodate such an application, subse- 
quent to the establishment of a two-way RTP voice path, a RE-INVITE message 102 
containing a new SDP for SIP EP B is received by CSP 2. CSP 2 responds by issuing a 
message 104 to host 4 to advise the application of the change in SDP for SIP EP B. CSP 
2 then executes an internal media data transfer 106 and issues a RE-INVITE message 108 
to SIP EP A. Subsequently, a two-way RTP data path 1 10 is established between SIP EP 
A and B. Those skilled in the art will understand that a given call may be directed 
through multiple changes in assigned switching model using the disclosed techniques. 

Fig. 6 illustrates the call flow for an application involving an interactive voice re- 
sponse (IVR) system 116, which may represent, for example, a prepaid calling card 
service, which is coupled to CSP 2 by a chosen type of time division multiplex (TDM) 
communication link (e.g., Tl, El, Jl, DS3, etc.). In this example, a two-way RTP voice 
path 1 14 is initially established between SIP EP A and CSP 2. In addition a two-way 
TDM voice path 1 12 is established between CSP 2 and IVR system 116. Through the 
combination of voice paths 1 12 and 1 14, a user at SIP EP A may interact (i.e., by enter- 
ing an account number and PIN, etc.) with IVR system 116. As a result of such interac- 
tion (i.e., the account is validated and the digits axe collected for the call the user wishes 
to make), the two-way TDM voice path 1 12 is no longer needed and is thus released. 
Ultimately, a direct two-way RTP voice path 118, that bypasses CSP's media switching 
hardware (indicating a mid-call transition from earlier traditional switching model to soft- 
switching model), is established between SIP EP A and SIP EP C, representing, for ex- 
ample, a long distance call. 

What is claimed is: 
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